[00:00.060 --> 00:08.040]  Our next talk comes from Turkey. It is with great pleasure to welcome and introduce you to Oskan
[00:08.040 --> 00:15.550]  Mustafa Akkus and his talk, The Vulnerability that Gmail Overlooked and Enabled Threat Hunting.
[00:20.300 --> 00:22.140]  Take it away, Oskan.
[00:25.970 --> 00:33.270]  Hello, I wish happy days to everyone. I am Oskan Mustafa Akkus. Today I'm going to talk about
[00:33.270 --> 00:37.970]  the threats that the SMTP protocol can pose and show you how large mail
[00:38.710 --> 00:45.570]  providers such as Gmail overlooked and enabled threat hunting. It makes me sad not to be in
[00:45.570 --> 00:51.350]  Vegas right now, but health is more important than anything, so please be careful and don't
[00:51.350 --> 00:59.770]  go out without a mask. First of all, I want to talk about myself. I'm a vulnerable researcher
[00:59.770 --> 01:05.030]  and penetration tester in Turkey. While studying sports science and technologies,
[01:05.030 --> 01:12.390]  I decided to leave the university and step into the world of cybersecurity. My purpose is to
[01:12.390 --> 01:18.530]  provide added value to the world of cybersecurity through the training I had given and the research
[01:18.530 --> 01:24.830]  I had conducted. I published security vulnerabilities on international platforms
[01:24.830 --> 01:33.010]  that I had discovered. I entries my exploit to CVE and EDP databases. You can also access my
[01:33.010 --> 01:41.560]  previous works on my personal blog pentes.com.tr. I would like to mention presentation schedule.
[01:42.050 --> 01:49.310]  First, we will focus on SMTP protocol structure and threats. We're going to analyze by sending
[01:49.310 --> 01:57.670]  training emails inspired by SMTP, and then we're going to review and result and scheme
[01:57.670 --> 02:04.190]  of the research. Finally, I'm going to share an explosive tool as a bonus with you.
[02:04.910 --> 02:15.350]  I don't have the DEF CON 28 badge today. Because of that, I am using DEF CON 26 and 27 badges.
[02:16.110 --> 02:22.590]  I miss it using them very much. So, let's start.
[02:24.090 --> 02:29.990]  Let's look at what SMTP is. Also, let's take a look at the structure of this protocol and
[02:29.990 --> 02:36.390]  examine the logic of operation. As everyone knows, SMTP is simple mail transfer protocol.
[02:36.390 --> 02:40.750]  As mentioned in the name, it's very simple protocol. We know that the simple structure
[02:40.750 --> 02:47.730]  can always pose a danger. So, new solutions and models contribute to the straightening of
[02:47.730 --> 02:54.070]  the simple structure. Different solutions were used for many security problems in SMTP.
[02:54.070 --> 03:02.550]  We're going to touch this issue again later. SMTP was published as IFC 788 by Postel in November
[03:02.550 --> 03:14.610]  1981. This protocol structure was finalized as IFC 821, IFC 2821, and IFC 5321.
[03:14.610 --> 03:23.470]  IFC 5321 is the last standard published in 2008. Today, there are famous structures that
[03:23.470 --> 03:30.250]  high mail transfer agent is the use of the SMTP protocol such as Gmail, Postfix,
[03:30.250 --> 03:38.730]  Microsoft Exchange Server, Yandex, Mail.ru, Yahoo, and so on. You can examine the history and
[03:38.730 --> 03:44.030]  final version of the SMTP protocol in detail through the link below.
[03:45.510 --> 03:51.430]  According to Internet Engineering Task Force, the simple structure of the SMTP protocol can
[03:51.430 --> 03:59.150]  be shown as follows. Let's follow a path from the simple structure to complex structure.
[03:59.150 --> 04:06.010]  Below, we can see the structure that is not separated into its components. So, SMTP clients
[04:06.010 --> 04:13.970]  communicate via the internet. Let's continue the review by adding protocol components. If we move
[04:13.970 --> 04:22.490]  to from general to detail, it will be more memorable. In the diagram below, you can see that we have
[04:22.490 --> 04:28.750]  divided the SMTP client and SMTP server into two components such as mail transfer agent and
[04:28.750 --> 04:34.330]  user agent. The user agent creates the envelope then puts the message in the envelope. So, it
[04:34.330 --> 04:40.610]  prepares the message. The mail transfer agent transfers his prepared mail across the internet.
[04:40.610 --> 04:47.050]  This is done in the same way on the parties receiving the mail and delivering the mail.
[04:47.050 --> 04:53.770]  Up this time, the SMTP protocol was in a very simple state. Spring made trails with the simple
[04:53.770 --> 05:00.330]  structure. Therefore, different structures are included to strengthen the SMTP protocol. For
[05:00.330 --> 05:09.110]  example, extended SMTP has been released. Extended SMTP defines a framework for extending SMTP
[05:09.110 --> 05:16.010]  service by defining a means whereby a server SMTP can inform a client SMTP as to the server
[05:16.010 --> 05:24.430]  extension it supports. So, control has been added to DNS site which is used especially for email
[05:24.430 --> 05:32.610]  transfer. Authentication to SMTP server, domain case identification mail, domain-based message
[05:32.610 --> 05:38.910]  authentication, reporting and conformance, and standard policy framework are the controls provided
[05:38.910 --> 05:44.870]  on the DNS site. While many standards have been published to strengthen the SMTP protocol,
[05:44.870 --> 05:51.750]  the most important of this is the standard policy framework. This will be the point we will focus on
[05:51.750 --> 05:57.890]  today. At this point, we will review the Internet Engineering Task Force's documents again. According
[05:57.890 --> 06:04.950]  to Internet Engineering Task Force, IFC 7108 is version 1 for standard policy framework for
[06:04.950 --> 06:12.570]  authorizing use of domains in email. You can get detailed information from the link below.
[06:12.570 --> 06:19.130]  There's a sentence like this in the abstract description. This sentence is exactly like this.
[06:19.130 --> 06:25.890]  Email on the internet can be forgotten in a number of ways. In particular, existing protocols place
[06:25.890 --> 06:31.650]  no restriction on what a sending host can use as the mail from of a message or the domain given on
[06:31.650 --> 06:38.430]  the SMTP hello, hello comments. This part is very important. Existing protocols place no restriction
[06:38.430 --> 06:44.730]  on what a sending host can use as the mail from of a message or the domain. This means that the
[06:44.730 --> 06:50.850]  SMTP protocol is a very primitive structure. It's ironic that the millions of the servers are not
[06:50.850 --> 06:58.310]  using mail from control while using this protocol. Our main subject today is how famous mail transfer
[06:58.310 --> 07:05.810]  agent services can pause a trade event thought they use SPF. In fact, today I was gonna just
[07:05.810 --> 07:12.670]  share a situation related to Gmail, but it was March 3 when I applied for Package Hacking Village,
[07:12.670 --> 07:19.210]  so I continued my research and perform a test on other famous email providers.
[07:19.290 --> 07:27.370]  So today we will examine also other famous mail providers, not only the Gmail. These will be
[07:27.370 --> 07:35.790]  Gmail, Yandex Mail, Mail.ru, Outlook, Hotmail, Yahoo, Zoho Mail, Hi.com, and HubSpot.
[07:35.810 --> 07:41.070]  Because of that, it will be more correct to change the presentation title as
[07:41.790 --> 07:47.240]  the vulnerability that famous email providers overlooked at enabling trade hunting.
[07:47.750 --> 07:54.610]  Let's send emails that can pause trades and analyze the situation later. I worked on Exploit
[07:54.610 --> 08:00.890]  to send these training emails. I'm so sorry to say that, but I'm not gonna share the details
[08:00.890 --> 08:07.290]  of Exploit because it's so dangerous. However, I'm gonna show you with live examples. I'm gonna
[08:07.290 --> 08:14.190]  use an SMTP server as a gateway by authentication with user information. This server will be an SMTP
[08:14.890 --> 08:21.190]  server without open relay. In addition, this server must be a trusted server that has been
[08:21.190 --> 08:27.770]  previously approved by famous email providers and has no problem with mail delivery. The server I
[08:27.770 --> 08:33.710]  use in Exploit for this process will be my university's mail server. The servers of large
[08:33.710 --> 08:42.790]  companies and universities are in constant communication with famous email providers,
[08:42.790 --> 08:51.510]  so we can bypass most of the DNS-based controls. If you try to do this by creating a new server,
[08:51.510 --> 08:58.110]  you're gonna definitely fail. There's also another detail in the Exploit I wrote about that,
[08:58.110 --> 09:06.530]  but I'm not gonna share these details as I said before. We're gonna conduct internal and external
[09:07.350 --> 09:13.830]  tests on famous mail providers. In internal tests, we will try to send arbitrary mail via
[09:13.830 --> 09:20.430]  mail providers' own domain name, for example, gmail2gmail. In external tests, we will try to
[09:20.430 --> 09:29.070]  send arbitrary mail using the domain name walloffship.com. Let's analyze these training
[09:29.070 --> 09:34.610]  emails by sending them. I created a special account on all of the famous email providers.
[09:34.610 --> 09:39.570]  We're gonna perform internal and external tests throughout these accounts. We're gonna do tests
[09:39.570 --> 09:49.170]  on Gmail, Yamnix Mail, Mail.ru, Outlook, Yahoo Mail, Zoho Mail, Hai.com, and HubSpot.
[09:49.170 --> 10:00.250]  My Gmail account was forwarded to HubSpot. It's also forwarded to Hai.com too.
[10:00.790 --> 10:08.810]  Therefore, we're gonna also test Hai.com and HubSpot with email we sent to Gmail.
[10:10.150 --> 10:16.250]  In internal tests, we will try to send arbitrary mail via mail provider's own
[10:16.250 --> 10:21.290]  domain name. And then we're gonna analyze the results.
[10:22.770 --> 10:32.610]  We're gonna send the mail from defconn.gmail.com to defconn.pishui.gmail.com first.
[10:32.930 --> 10:42.660]  Let's start with Gmail. I'm gonna send it.
[10:43.300 --> 10:52.220]  It will be passed. We need to wait a little.
[10:56.250 --> 11:03.390]  And mail has been sent successfully. As you can see, the mail dropped on the inbox.
[11:03.390 --> 11:08.050]  However, there's a big warning that this mail could not be verified that it came from
[11:08.050 --> 11:17.170]  defconn.gmail.com. But when we look at Hai.com, there is no warning here.
[11:17.850 --> 11:25.070]  This is a very dangerous situation. Similarly, when we check the HubSpot,
[11:25.070 --> 11:30.750]  we see that the mail is successfully forwarded and does not contain any warning too.
[11:31.870 --> 11:35.430]  I'm gonna explain the source of this vulnerability to you later.
[11:36.050 --> 11:39.230]  Let's continue our test with Yandex Mail.
[11:39.310 --> 11:45.890]  Now I'm gonna send email from defconn.yandex.com to defconn.pishui.yandex.com.
[11:45.890 --> 11:51.950]  I'm passing information here.
[11:52.270 --> 12:04.650]  Yeah, mail has been sent successfully. I will check the inbox.
[12:04.650 --> 12:08.710]  And I reflect the page and check the inbox and spam box again.
[12:10.710 --> 12:16.470]  But no email came. Yandex didn't allow us to construct its own domain name.
[12:17.050 --> 12:25.270]  So let's continue the test with mail.ru. I'm gonna send email from defconn.mail.ru
[12:25.270 --> 12:32.550]  to defconn.pishui.mail.ru. I'm passing information.
[12:40.750 --> 12:46.150]  Mail has been sent successfully. I will check the inbox.
[12:52.100 --> 12:55.000]  I'm gonna check back again to make sure.
[13:00.010 --> 13:07.090]  No email came. Mail.ru didn't allow us to control its own domain name such as Yandex.
[13:07.690 --> 13:16.810]  So let's continue the test with Hotmail. I'm gonna send email from defconn.hotmail.com
[13:16.810 --> 13:31.720]  to defconn.pishui.hotmail.com. Mail has been sent successfully.
[13:32.580 --> 13:39.680]  I'm checking the inbox. No email inbox, but as you can see it dropped into the spam box.
[13:40.580 --> 13:46.020]  The mail is here. And let's continue the test with Yahoo Mail.
[13:46.320 --> 13:53.020]  I'm gonna send email from defconn.yahoo.com to defconn.pishui.yahoo.com.
[14:02.680 --> 14:07.740]  Mail has been sent successfully. I'm checking the boxes.
[14:20.160 --> 14:22.540]  Oh, Trump came to his own mail.
[14:25.020 --> 14:30.560]  And no mail came. Yandex didn't allow us to control its own domain name too.
[14:30.560 --> 14:36.980]  Let's continue the test with Zoho Mail. I'm gonna send email from defconn.zohomail.com
[14:36.980 --> 14:54.750]  to defconn.pishui.zohomail.com. Mail has been sent successfully.
[14:56.810 --> 15:04.000]  Let's check the page by reflashing. I'm checking the boxes.
[15:08.270 --> 15:12.310]  No mail came. Zoho didn't allow us to control its own domain name too.
[15:12.310 --> 15:15.910]  So internal tests are over. We can pass to external tests.
[15:16.210 --> 15:20.130]  Time to external tests. I'm gonna use the email address mink
[15:20.130 --> 15:25.090]  at walloffship.com for external testing. We're gonna send email from mink at
[15:25.090 --> 15:29.730]  walloffship.com to other email addresses. Let's start with Gmail.
[15:29.890 --> 15:44.700]  I'm passing. Mail has been sent successfully.
[15:44.760 --> 15:48.180]  At the same time, the mail dropped into the inbox already.
[15:48.300 --> 15:52.720]  As you can see, we cannot see the warning here as internal tests.
[15:52.720 --> 15:56.060]  When you browse the first mail, you can see the difference,
[15:56.060 --> 16:00.580]  but there is a small detail. There is a question mark in the profile photo.
[16:00.620 --> 16:06.500]  When we move the cursor to this point, we notice that there is a warning again here.
[16:06.500 --> 16:13.440]  It says your mail could not verify that walloffship.com actually sent this message.
[16:13.440 --> 16:21.320]  But I don't know which user cares about this. I'm gonna show an example later on this situation.
[16:22.060 --> 16:29.820]  Let's check out hey.com and HubSpot now. As you can see, mail has been forwarded
[16:29.820 --> 16:36.480]  without any warning such as an internal test. The situation looks the same for HubSpot too.
[16:37.100 --> 16:41.480]  There is no warning and mail is cleanly forwarded.
[16:41.480 --> 16:46.100]  I also want to show you what's happening in the Gmail application.
[16:47.640 --> 16:53.740]  I'm gonna show you an older version. There is no warning even in the profile
[16:53.740 --> 16:59.440]  photo in the mobile application. However, until two months ago,
[16:59.440 --> 17:03.840]  it was affected by this weakness in the last version.
[17:03.840 --> 17:10.680]  I didn't report them, but they fixed the vulnerability. I don't know how they learned.
[17:12.500 --> 17:16.760]  Maybe my mails may be under review. I don't know.
[17:17.140 --> 17:23.620]  But still, I want you to know that the old versions are still vulnerable.
[17:24.740 --> 17:29.960]  Let's continue tasks with Yandex Mail. I'm gonna send email from
[17:29.960 --> 17:34.740]  mink at walloffship.com to defcomph3 at yandex.com.
[17:36.580 --> 17:52.560]  I will pass the information. Mail has been sent successfully.
[17:54.160 --> 18:03.680]  I will check inbox. As you can see, mail dropped directly into the inbox.
[18:03.680 --> 18:09.220]  Also, there is no warning in the mail content. It's a very dangerous situation.
[18:09.280 --> 18:12.440]  I'm not Mink, but it doesn't matter for Yandex.
[18:13.000 --> 18:17.720]  Therefore, we can say that Yandex is affected by this situation.
[18:18.240 --> 18:24.660]  I'm taking note of this and let's continue tasks with mail.ru.
[18:25.220 --> 18:32.180]  I'm gonna send email from mink at walloffship.com to defcomph3 at mail.ru.
[18:44.110 --> 18:51.360]  Mail has been sent successfully. As you can see, the mail has arrived quickly.
[18:51.920 --> 18:57.300]  Just like Yandex, mail.ru didn't check if I was Mink or not.
[18:57.300 --> 19:02.860]  Therefore, we can say that Yandex is affected by this situation too.
[19:03.160 --> 19:08.740]  Let's continue tasks with Hotmail. Now is I'm gonna send email from
[19:08.740 --> 19:14.060]  mink at walloffship.com to defcomph3 at hotmail.com.
[19:28.090 --> 19:34.650]  Mail has been sent successfully. Now I will check.
[19:35.590 --> 19:40.510]  And no mail inbox, but as you can see, it dropped into the spam box.
[19:40.610 --> 19:45.500]  Hotmail sent this message to the spam box because it couldn't verify its owner.
[19:45.910 --> 19:51.260]  So I am taking note of this. Let's continue tasks with Yahoo mail.
[19:51.690 --> 19:57.510]  I'm gonna send email from mink at walloffship.com to defcomph3 at yahoo.
[19:57.530 --> 20:15.890]  com. Mail has been sent successfully.
[20:17.270 --> 20:31.470]  I'm checking the boxes. I'll tramp again, I think tramp is after me.
[20:31.870 --> 20:34.730]  I will check boxes a few times to be sure.
[20:39.810 --> 20:45.050]  No mail has been received. Yahoo is very strict about this.
[20:45.050 --> 20:50.210]  I take note of this and pass the final external test of Zaha mail.
[20:50.210 --> 21:09.970]  I'm gonna send email from mink at walloffship.com to defcomph3 at zahomail.com.
[21:10.010 --> 21:14.310]  Mail has been sent successfully. I'm checking the boxes.
[21:18.850 --> 21:24.250]  And no mail has been received, so Zaha mail is very strict about this, such as Yahoo.
[21:24.770 --> 21:30.030]  This was our last test. It's time to analyze the information we collect.
[21:31.090 --> 21:35.210]  As an example of my research, I caught a very interesting example.
[21:35.230 --> 21:41.210]  I want to present this to you. My friend was accepted by defcom Red Team Village.
[21:41.210 --> 21:48.670]  This news came to him from omar at redteamvillage.io.
[21:48.750 --> 21:55.090]  When I review this email, there's a warning in the Gmail proper photo area, just like our external
[21:55.090 --> 22:01.290]  test. My friend did not pay attention to this situation and answered this email.
[22:01.930 --> 22:08.770]  Fortunately, the mail really came from Omar, but this could be a fake mail.
[22:08.910 --> 22:16.570]  Now I'm gonna send an email from omar at redteamvillage.io to my friend gmail artist.
[22:17.230 --> 22:20.550]  We're gonna also carry out internal and external testing and
[22:20.550 --> 22:27.630]  look at the response of the email application on the Apple Mac device to this vulnerability.
[22:28.570 --> 22:35.430]  Let's send the mails. I'm gonna send these test mails from my second screen.
[22:41.450 --> 22:50.390]  As you can see, the mail from defcom at gmail.com also cancels a warning in the Gmail web application.
[22:51.070 --> 22:58.610]  However, in the email application of the Mac operating system, this mail does not
[22:58.610 --> 23:03.290]  cancels any warnings. This is a very interesting finding, too.
[23:03.730 --> 23:09.750]  In addition, the mail I sent from Omar successfully reached the application
[23:09.750 --> 23:19.290]  allowed me to pass whether I was Omar or not. Now, time to examine where this vulnerability is
[23:19.290 --> 23:26.130]  caused. Now I'm gonna show where the vulnerability originated. As I have shown before,
[23:26.130 --> 23:32.010]  we're gonna examine why third-party applications cannot detect this little warning in the profile
[23:32.010 --> 23:37.930]  photo area and why are they receiving this training mail cleanly from Gmail.
[23:38.030 --> 23:42.590]  Let's look at what's happening again. Hair.com does not have any warning.
[23:43.430 --> 23:50.330]  Also, HubSpot does not have any warning, too, as you can see.
[23:51.050 --> 23:58.290]  Mail that is perceived as dangerous in Gmail looks completely clean on these platforms.
[23:58.290 --> 24:02.230]  To show that, I'm gonna use Python library writing for the Gmail API.
[24:02.230 --> 24:08.380]  With this library, we're gonna check the email contents by making a request to the Gmail API.
[24:09.130 --> 24:14.750]  First, we need to learn the ID value of the message we want to link.
[24:16.890 --> 24:24.010]  And I think that should be it. I need to put this ID value into the library properly.
[24:24.010 --> 24:31.450]  We also need to use GET instead of LIST. It is now ready to make request again.
[24:32.700 --> 24:38.930]  As you can see, all the details of the mail are here. After a little examination,
[24:39.290 --> 24:45.450]  we realized that the warning in the Gmail web application is not among the information
[24:45.450 --> 24:53.490]  received with the Gmail API. Therefore, we have proved that third-party applications such as
[24:53.490 --> 24:59.410]  Hair.com, HubSpot, and Apple email applications cannot detect this warning because
[24:59.410 --> 25:07.070]  they use the Gmail API. There are dozens of applications using the Gmail API,
[25:07.070 --> 25:14.710]  so this vulnerability caused by Gmail affects them all. In this case, it leaves millions of
[25:14.710 --> 25:22.390]  people directly in danger. These applications which can connect with Gmail need to make a
[25:22.390 --> 25:31.810]  new update considering this situation. Once and for all, let's examine the result of our internal
[25:31.810 --> 25:37.330]  and external test again. Let's take a brief look at the result of our test.
[25:37.330 --> 25:45.590]  I'm going to summarize this part quickly. The meaning of the signs are here. In internal tests,
[25:45.590 --> 25:54.190]  training mails drops into the inbox with warning in Gmail and doesn't drop into any box in Yandex
[25:54.190 --> 26:02.950]  and doesn't drop into any box in Mail.ru and drops into the spam box in Outlook and doesn't drop
[26:02.950 --> 26:10.990]  into any box in Yahoo and doesn't drop into any box in Zahoomail too. In external tests,
[26:10.990 --> 26:18.950]  the training mails drops into the inbox without warning in Gmail and drops into inbox without
[26:18.950 --> 26:28.670]  warning in Yandex and drops into the inbox without warning in Mail.ru and drops into the spam box in
[26:28.670 --> 26:36.730]  Outlook and doesn't drop into any box in Yahoo and doesn't drop into any box in Zahoomail too.
[26:36.770 --> 26:43.470]  Unfortunately, third-party applications using APIs of famous mail providers cannot reflect
[26:43.470 --> 26:49.450]  warnings. Initially, the incoming email is forwarded directly without an error message.
[26:49.750 --> 26:56.650]  So, Hide.com forwarded training mails and mails dropped into the inbox without warning. Also,
[26:56.650 --> 27:03.610]  HubSpot forwarded training mails and mails dropped into the inbox without any warning too.
[27:03.610 --> 27:10.130]  This was the test result with it. I'm sharing an exclusive tool with you at the last stage of my
[27:10.130 --> 27:17.170]  presentation. Its name is DraftChat. DraftChat allows persons to chat throughout mail providers.
[27:17.170 --> 27:23.570]  You can access the GOD chat module, which is the first module and uses the Gmail API.
[27:24.130 --> 27:30.810]  DraftChat allows persons to chat throughout a single Gmail account in the Gmail that does not
[27:30.810 --> 27:41.550]  record drafts. It encrypts the sent message first with DES and then with the AES algorithm and writes
[27:41.550 --> 27:49.490]  them to the created draft. The message of person I've written in encrypted form on the same draft.
[27:49.490 --> 27:56.450]  Message can only be read with the correct case to be determined. In this way, a completely hidden
[27:56.450 --> 28:02.850]  chatroom is created with a single Gmail account. Therefore, DraftChat makes person-hundred private
[28:02.850 --> 28:10.230]  communication opportunity by turning a non-URL mail server into a chat server. You need to set
[28:10.230 --> 28:16.530]  up a common Gmail account to chat with your partner. Remember, you will only perform this
[28:16.530 --> 28:23.650]  operation once. You will not have to do this configuration every time you chat. Let's do the
[28:23.650 --> 28:30.730]  installation pace in a practical way. First step is turn on the Gmail API. First of all, we need to
[28:30.730 --> 28:35.950]  allow for quick start from our Gmail account, because we are using fighting quick start. Click on
[28:35.950 --> 28:44.410]  enable the Gmail API button. In this section, you should choose the desktop. In zone link dialog,
[28:44.410 --> 28:51.310]  click download client configuration and save the file credentials.json to your DraftChat directory.
[28:51.310 --> 28:59.130]  After running DraftChat, it will first ask you for your nickname. Once you have determined
[28:59.130 --> 29:05.870]  your nickname, you must determine whether you want to be a server or a client. Client-server
[29:05.870 --> 29:13.930]  relationship is very simple. If you want to be a server, the DES and AES keys that you determine
[29:13.930 --> 29:20.670]  will be used. If you choose to be a client, you have to get keys for these algorithms from your
[29:20.670 --> 29:29.870]  server partner. Let's say you choose the server option. After the retirement and 8-digit DES key,
[29:29.870 --> 29:38.010]  DraftChat generates a 16-digit random AES key for you and a new draft is created for the chat rooms
[29:38.010 --> 29:44.330]  that your client partner is expected. So you need to pass this case over to your partner.
[29:45.070 --> 29:50.650]  Let's take a look at the client option. In this case, I have taken an entrant from the server
[29:50.650 --> 29:57.350]  partner. If the keys are wrong, there is no server rating for the client, the program will give an
[29:57.350 --> 30:04.450]  error. The taken keys were entered and the information was verified. So you can communicate
[30:04.450 --> 30:10.530]  with your partner in peace of mind. When the draft box of our Gmail account is checked,
[30:10.530 --> 30:18.550]  you can see that a new draft has been created here. All messages are written here and the draft
[30:18.550 --> 30:26.290]  is continuously encrypted with algorithms. We can test this by writing a new message.
[30:28.450 --> 30:34.870]  It's for grids. The fact that you are offered a private chat room does not mean that the
[30:34.870 --> 30:42.390]  communication you provide while using this tool may be illegal. Remember that all the responsibility
[30:42.390 --> 30:49.430]  belongs to you. You can download DraftChat from GitHub. It also opened the development. You can
[30:50.070 --> 30:56.670]  contribute to this tool if you wish. Yes guys, now it's over. Thank you so much for listening to me.
[30:56.670 --> 31:02.230]  You can contact me from my social media accounts and you can ask your question whenever you want.
[31:02.230 --> 31:08.330]  I was honored to be here at DEF CON 28 Package Hacking Village. I hope to present my research
[31:08.330 --> 31:14.270]  at that best hacking conference in the world next year again. I wish healthy days to everyone.
[31:14.270 --> 31:15.950]  Best regards. Goodbye.
